The information-communication industry is an essential element of today's society, which is relied upon heavily by most companies, businesses, agencies, educational institutions, and other entities, including individuals. As a result, information service providers such as telephone, cable, and wireless carriers, Internet Service Providers (ISPs) and utility companies all have the need to deploy effective systems suitable for servicing such a demand. The importance of such information service providers rapidly deploying new systems and system elements and altering their existing management systems to accommodate evolving business and network requirements as needed has been recognized in the prior art. For example, it has been recognized that information service providers desire the ability to integrate existing network equipment and systems with new elements and applications, customize existing systems and applications, and scale systems to accommodate growing networks and traffic volumes.
Network management and operations have become crucial to the competitiveness of communication companies, utilities, banks and other companies operating Wide Area Networks (WANs) of computer devices and/or other network types and devices, including SONET, Wireline, Mobile, etcetera. For instance, many companies currently use customized “legacy” network management systems (NMSs) and operations support systems (OSSs). Various implementations of NMSs/OSSs are available in the prior art for managing networks and network elements.
Thus, management systems have been implemented in the prior art for managing communication networks and network elements. Communication networks are not static, and therefore management behavior for managing communication networks does not remain static. For example, various types of equipment from different vendors are commonly being coupled to Internet Protocol (IP) networks (such as the Internet), which often results in different management solutions being implemented for equipment supplied by different vendors. For example, when a network provider introduces a new type of equipment (e.g., from a new vendor) into an IP network, the management solutions implemented for the IP network typically have to be modified. For instance, the network provider has to modify the software code for the network management program in order to support this new equipment type. To modify the software code, the network provider typically must either manually write the code modifications or purchase from the vendor suitable code for managing the new equipment. In either case, this prior art technique of modifying the management software for new device types added to a network is problematic because it delays the capability of managing an added device. Such a delay or an interruption in the management of the network elements (e.g., devices) is typically undesirable to a network provider because an event may occur that affects the network elements during the delay/interruption and the network provider would have no knowledge of such event.
Another limitation that exists in prior art network management solutions arises regarding modification of management behavior. For example, a network provider may, from time to time, want to change the behavior of a network management system. For instance, a network provider may want to change the actions that are triggered by the network management system in response to a device failing (e.g., change a user alert that is presented responsive to such a device failure, or change the polling interval for retrieving variable information, such as CPU usage, memory capacity, etc. for a device). Network management systems may provide tools, such as a user interface, that allow a network provider to make such behavioral changes (e.g., by coding new behavior into the system). However, such behavioral changes cannot be implemented during run-time of a management system. That is, when network providers want to make a behavioral change in prior art management systems, they have to freeze the system, make the changes, and then unfreeze the system to activate the new management behavior. In the meantime, minutes to hours may be lost for managing the network elements. Again, such lost management time is generally undesirable to network providers.
Another common limitation in prior art management solutions is the centralized (e.g., non-distributed) nature of most solutions. Centralized solutions have limited capabilities as they tend to have performance problems and generate too much traffic as well. Also, they cannot intrude through firewalls and manage devices behind firewalls. This also limits their ability to manage multiple customer networks and resolve other issues that may exist within a network.
Thus, with prior art network management systems, network providers must spend time rewriting the management software code or purchase custom management code from the vendor to manage a new device and/or to implement behavioral changes. In either case, the network provider must obtain the new code for managing devices the way they want them to be managed, and then the management system must be shut down to load the new management code on the system. Thus, there is down time in loading the new code during which the providers network is not managed. Accordingly, new management behavior cannot be implemented in prior art management systems without interrupting management of the network elements (e.g., because of shutting the management system down).
Prior art network management systems commonly recognize faults (or “traps”) generated within the network and/or utilize polling of the network elements to provide management. For example, IP and Simple Network Management Protocol (SNMP) devices may generate fault messages (which may be referred to as traps), which are unsolicited messages that may be received by the management system. Examples of such trap messages include messages that indicate a network element's CPU utilization is too high, a network element just rebooted, available data storage capacity is low on a network element, an interface on a network element is down. Various other types of unsolicited trap messages may be generated by a network element and received by a network management system, as those of ordinary skill in the art will recognize. Such messages are generally generated in a defined protocol, such as SNMP, which the management system can recognize to process the received messages.
Various challenges may be encountered in utilizing such trap messages in a network management system. An example of one challenge is that a vendor may, from time to time, change or add trap messages that may be generated by a particular device. For instance, a management system may expect to receive any of fifteen different messages from a certain device. However, the vendor for such device may modify two existing messages that the device is capable of generating and add four new messages capable of being generated by the device to result in a total of nineteen different messages that may be generated by the device. In response to such a change by the vendor, a network provider typically is required to modify the management software code to account for such message changes/additions, which may be very time consuming.
As IP networks grow to include hundreds to thousands of devices, which may be provided by different vendors and be very distributed (e.g., provided in different locations), modifying management system behavior to account for such a continually changing network topology becomes very difficult.